home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Ham Radio 2000
/
Ham Radio 2000.iso
/
ham2000
/
packet
/
aprs75c
/
digis.txt
< prev
next >
Wrap
Text File
|
1995-11-23
|
20KB
|
331 lines
DIGIS.TXT 7.4c AUTOMATIC PACKET REPORTING SYSTEM DIGIPEATERS
To satisfy the objective of a distributed network without dependence
on specific nodes, APRS stations are designed to begin operating without
any prior knowledge of the network. This is done by having all APRS
digipeaters and home stations initialized to act as a digipeater with
the alias of RELAY and to send all UI frames via the UNPROTO path of
RELAY. With this form of generic digipeating (RELAY), a mobile, or new
station does not have to know anything about the network in advance in
order to be seen by adjacent nodes. After 10 minutes and his map begins
to show the location of all stations and digipeaters on frequency, he can
then customize his outgoing Unproto path to specific digipeaters to cover
his intended area without as much QRM.
CAUTION: Since the preferred APRS frequency of 145.79 is adjacent to the
SATELLITE band at 145.8, all APRS users should run minimum power. High
and WIDE digipeaters in residential areas or near other satellite ops
should operate at 10 watts or lower to minimimze QRM. The purpose of
APRS digipeaters is to HEAR mobiles, NOT to be an aligator!
It is important in any mature APRS network that FIXED stations should
avoid using the generic RELAY addressing. Although mobiles should usually
begin their path with RELAY,WIDE, the path of RELAY should rarely be used
after the first hop, and never after a WIDE. The D-list command lets you
see what digipeater paths other stations are using and it also marks
stations that you can hear direct. Also under the OPS-DIGI command, users
can save up to 12 different DIGIpeater paths. Users can select any given
path that is optimum for their present application with a single key
stroke. The MAPS-PLOTS-POWER command will display a range circle
around all stations proportional to their power, antenna height above
average terain, and gain. Users can use these plots to estimate what
paths, through what stations, might be useful.
Although digipeating is not good practice for AX.25 level 2
connections, it is ideal for APRS operation using UI frames only. All
along the east coast we have more than a dozen WIDE area DIGI's on the
frequency of 145.79 acting as a backbone for mobile position reporting.
The low duty cycle of this mode, also permits Keyboard QSO's and other
UI frame applications. Even Personal mail boxes are welcome on the
frequency, since mail is posted at keyboard rates and is NOT read back
by radio. Users are NOT welcome to READ PBBS mail on the frequency.
Other CONNECTED mode operation of BBS's, mail forwarding, file transfers,
TCP-IP and DX clusters are discouraged.
APRS DIGIPEATERS: In addition to all the home station RELAYS, additional
APRS RELAY digipeaters can be installed where ever needed to provide
solid mobile coverage on all major access routes into your city. These
sites provide the first hop (via RELAY) for all mobiles. Next, a few
well elevated and WIDEly separated digipeaters should be installed which
have not only the RELAY alias, but also a WIDE alias. These WIDE sites
link to other cities and provide a backbone for wide area coverage.
WIDE DIGIPEATING: Since these WIDE area digipeaters are located at
excellent locations, they should not only provide the WIDE backbone
function for the long-haul, but should also have the RELAY alias as well
for nearby mobiles and new stations. Many recent TNCs can be set up to
digipeat either of these generic RELAY/WIDE packets. The new PacComm
TNC's can support up to 4 aliases!. Set MYAlias to WIDE and set one of
the other TNC functional callsigns to RELAY (such as MYnode, or MYhost,
etc). If you use the KPC-3 and the MYnode call, be sure to set USERS
to 1 and NUMNODES to 1. If your TNC does not have dual aliases, AND
yours is the only WIDE around, you can temporarily make its MYcall be
WIDE and its MYalias be RELAY, but be sure to put the FCC callsign in
the BText to keep it legal. You can also have one other DIGI with the
opposite MYcall RELAY and MYalias WIDE without confusion. These WIDE/
RELAY backbone Digi's should be spaced several tens of miles apart
depending on topology so that they are as widely separated
while still being able to hit their adjacent other WIDE digi's. All
mobiles then can set their UNPROTO path to APRS VIA RELAY,WIDE and it will
not matter whether they are near a DIGI or someone's home station to be
picked up by the network.
Even if these WIDE/RELAY backbone nodes are 30 to 50 miles apart, as
long as every home station and local RELAY digipeater can hit at least
one WIDE, then the mobile path of RELAY,WIDE can cover as far as 100
miles! Wider ranging mobiles can use the RELAY,WIDE,WIDE path without
causing too much QRM. Yes, RELAY,WIDE,WIDE should NEVER be used by a home
station, but since a mobile can rarely, if ever, hit more than 1 digi the
first time, the number of repeats is not much worse than a typical home
station via WIDE,WIDE.
CAUTION: Fixed stations that can hit 2 or more WIDES should NEVER use three
generic RELAY/WIDE callsigns in a row, and RELAY should NEVER be anywhere
except the FIRST in the list. FIXED stations should always avoid any
GENERIC calls if possible after the first two. Although generic paths
for mobiles are the normal mode of operation, special consideration must
be given whenever there will be a great convergence of generic mobiles
using RELAY,WIDE paths. Remember, every APRS station INCLUDING MOBILES
will also have the ALIAS of RELAY, so when they all get within range of
each other, there is quite a conflagration! To minimize these problems
here are the typical recommended settings for ALIASES and PATHS:
TYPICAL MOBILE (1-5 watts): UN APRS V RELAY,WIDE MYAlias = RELAY
(25-50 w ): UN APRS V WIDE,WIDE MYAlias = RELAY
STAND ALONE TRACKERS: MYAlias = NONE
All Mobiles converging to one location should hit CONTROLS-BANDS-HF which
will change their MYAlias from RELAY to ECHO. This will eliminate everyone
from digipeating everyone else's VIA RELAY packets. They should also
choose a new UNPROTO path specific to that location, without beginning
with RELAY! The alias of stand-alone trackers should be typicaly set
to NONE since they cannot be quickly changed in the field.
DEDICATED WIDE AREA APRS DIGIPEATER SET UP
To set up a WIDE area APRS digi, simply connect a TNC to a radio, and put
it as high as you can get it. Set the following minimum commands:
cmd: MY W3XYZ-x (the digipeater call and SSID)
MYA WIDE (this makes it digipeat WIDE packets)
MYN RELAY (This works on KPC-3s as a second alias
MYG RELAY (on PK-12)
UNPROTO APRS VIA WIDE,WIDE,DIGI3... (so the whole net sees it)
B E 60 (Sets Beacon to once every 10 minutes)
BT !DDMM.mmN/DDDMM.mmW#PHG5360/WIDE-RELAY...(identifying comments)
| | | | |||| |___|_ makes station show up green
| | | | ||||________ Omni (Direction of max gain)
| | | | |||_________ Ant gain in dB
| | | | ||__________ Height = log2(HAAT/10)
LAT LONG | | |___________ Power = SQR(P)
| |_____________ Power-Height-Gain PHG indicator
|_______________ # is symbol for digipeater
As you can see by the integers in the POWER-HEIGHT-GAIN (PHG) string, there
are only 9 plus 0 possible values for each of these fields as follows:
DIGITS 0 1 2 3 4 5 6 7 8 9 as used in the Pwr field
-------------------------------------------------------------------------
POWER 0, 1, 4, 9, 16, 25, 36, 49, 64, 81 watts SQR(P)
HEIGHT 10,20,40, 80,160,320,640,1280,2560,5120 feet LOG2(H/10)
GAIN 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 dB
DIR 0,45,90,135,180,225,270, 315, 360, . deg D/45 This offsets
* the range circle in the
* 0 means OMNI indicated direction
HEIGHT ABOVE AVERAGE TERRAIN: Going out 10 miles in all directions, write
down the elevation every 2 miles or so. Average all these points and
compare your elevation to the average. You may be at 2000 feet above
sea level and have a 150 foot tower, but if the ground around you is at
2200 feet, then your HAAT is -50 feet!!! Be honest! Your circle should
go no further than the distance to which you can reliably copy an HT!
Even though you have an OMNI antenna, if the terrain favors a certain
dierction, then put that in for your directivity.
NOTE ABOUT POWER LEVELS: In order to be good neighbors to the satellite
users at 145.80, there is little justification for making a WIDE
area digi run any more power than 10 watts. The function of the WIDE-RELAY
nodes are to HEAR MOBILES and to relay those posits to fixed stations. The
mobile is usually at ground level and is using an omni directional whip.
If his path gets him into the digipeater, then he should be able to hear
it. Home stations with higher antennas can easily hear the digipeater.
Both WIDE area digipeaters that I have installed use only about 5 watts.
Running high power just adds QRM beyond the effective range of the repeater.
X1J DIGIPEATERS: You may set up an X1J node to act as a generic
WIDE area APRS digi, depending on whether the ALIAS callsigns are not
already in use. The X1J permits 5 callsigns. The first two are the NODE
callsign and the NODE alias. These pertain to level-4 NODE operation and
can NEVER be made WIDE or you will LOCK-UP the network. The next three
ALIASES are for a BBS, DXCLUSTER or HOST mode operation. By enabling two
of these extra aliases to WIDE and RELAY, then the node will digipeat APRS
UI frames as long as the following commands are also performed:
PARM / 23 1 Digipeat enable (info provided by WA4HEI 906 341-5718)
MODE / 14 1 Extra alias monitoring enable
MODE / 17 3 Refuse digipeated L2 node uplinks & downlinks
OPERATIONS WITH RELAY AND WIDE:
Although the GENERIC WIDE/RELAY digipeating works well to get an APRS
net going, once you have more than two WIDES, the generic calls should be
avoided by all fixed stations to minimize unnecessary duplicates and
collisions. Using SPECIFIC callsigns significantly reduces QRM.
While building a new network, APRS has a special SETUP-WIDE command
that permits some well situated stations to change their default RELAY
alias to WIDE. This command should be used with caution and with the
agreement of all stations on the net. Too many WIDE's, too close together
causes too much QRM. When you use the SETUP-WIDE command, the word WIDE
will be installed in your POSIT comment field. This signals all stations
to display your station symbol as GREEN (which indicates a WIDE alias).
This color will be lost, however, if you have a weather station
hooked up to COM2, since it re-writes the POSIT string every few minutes.
Also, every time you switch from HF to VHF or the reverse, your ALIAS is
re-written to RELAY or ECHO.
SEE README.HF for setting up your UNPROTO path for HF and HF/VHF gateways..
********** WIDE-N ALL DIRECTION GENERIC DIGIPEATING! ****************
THE ULTIMATE SOLUTION FOR MOBILE POSITION REPORTING
This may be the simplest mechanism for making an order of magnitude
improvement in APRS status and position reporting networks. In a WIDE-N
network, each WIDE digi simply repeats ANY packet with the VIA address of
WIDE-N; but ONLY ONCE. If it keeps a copy of the last 30 seconds of packets,
(or at least a copy of the FCS) and compares each new packet that it hears
with the LAST one that it digipeated, then it could decide NOT TO TRANSMIT
it again! This would completely eliminate the multiple round-robin
multiplication of packets generated when a mobile station uses the present
generic path of WIDE,WIDE,WIDE. As it is now, such a 3 tier path launched in
the middle of 3 WIDE digipeaters that all hear each other can generate as many
as 3x3x3 or 27 duplicates in the area. If each WIDE-N only digipeated the
packet once, then there would only be 3 local copies generated, and the packet
would still propagate outward 3 levels in all directions in the usual manner!
Since this algorithm has uses on ALL amateur packet networks needing a
FLOODing mechanism for special packets of interest to everyone, I am calling
it the FLOOD-N algorithm. For APRS, however, I will still refer to it as
the WIDE-N algorithm.
NUMBER OF HOPS: Using the via path of WIDE-N, each DIGI that repeats the
packet decrements the WIDE-SSID by one. This way, each packet carries along
with it information on how many times it has bounced through the network.
The user specifies how far it goes, by the initial setting of the SSID!
If he sets it to WIDE-7, then the packet could be digipeated as many as
seven times outward. A local commuter might select WIDE-2 to cover his
area while limiting DX QRM.
NEW TNC COMMANDS REQUIRED: To make this work, there are three new TNC
commands needed:
MYFlood: This command, similar to MYAlias, sets up the callsign at the
digipeater to be used as the FLOOD-N callsign. In APRS networks, we
will use WIDE. THIS IS FOR UI FRAMES ONLY! That plus the AGELimit
below, makes it un-useable for connected frames, and for abuse.
HOPLimit: This is a SYSOP parameter that can be used to limit the
maximum number of HOPS permitted in a network. Already the maximum
number of hops is limited to 7, since the upper bit of the SSID is
reserved for future use. However, on NON-APRS networks, some SYSOPS may
feel empowered to limit the maximum number of hops to some smaller number.
AGELimit: The WIDE-N digi has to keep a copy of all digipeated packets
for a brief period for comparison with new packets heard. This is the
key to the WIDE-N algorithm. Every digi that hears a UI packet will
digipeat it, BUT ONLY ONCE. To do this, it compares each new packet with
all packets digipeated in the last X seconds. This X age-limit needs to
be a variable depending on the speed of the network. If the time is too
long, then the list is big, If it is too short, then there is the chance
that a packet may propogate in a circle and get repeated again. My guess
is that 30 seconds is a good default value for 1200 baud channels. Howie
Goldstein, N2WX has improved the effeciency of this idea, by only saving
and comparing the CHECKSUM of the packets, instead of the whole packet.
If ALL APRS WIDE area digipeaters changed over to the WIDE-N code, we
would HAVE THE ULTIMATE GENERIC MOBILE GPS NETWORK! Metropolitan area
commuters could set their digi paths to WIDE-2 and Mobiles on extended trips
within a 200 mile radius of home could be tracked with a path of WIDE-5,
without fear of clogging the network! This WIDE-N algorithm is so powerful
that it could even be added to ALL TNC's as a FLOOD-N mode. It would only
work on UI frames and would default to the generic callsign of FLOOD.
That way, on ANY packet frequency, a UI frame launched into the air, could
be seen by EVERYONE!
LEVEL FOUR and TheNET CONSIDERATIONS:
Since NODES are so much smarter than digipeating, the ultimate solution
is to have the NODES do all UI frame routing. The APRS station simply sends
his UI frame TO APRS VIA HOME; Any NODE hearing that transmission that has
knowledge of the route to HOME, will send the single packet via the NODE
network (internode, level 4) to the HOME node! When it arrives at the HOME
node, it is transmitted once as a UI frame. With this arrangement, a mobile
only has to specify his one intended destination, no matter where he travels!
The G8BPQ TheNET code for the DataEngine includes a DIGIon command that
can restrict Digipeating to UI frames only. This is very useful, in that it
allows SYSOPS to leave DIGI ON without inviting LEVEL-3 connects to use it
which is detrimental to normal level-4 operation. The problem, however, is
that the generic APRS RELAY and WIDE aliases cannot be used on a NODE, since
the digipeat ALIAS is the same as the NODE alias, and you cannot operate more
than one NODE with the same ALIAS on the same frequency or even in the same
network! I got a call yesterday, 22 Nov 95 that G8BPQ has now agreed to add
two more UI digipeater aliases that are not tied to any of the node functions.
DIGI/NODE COMPATIBILITY: Since the user should not have to change his digi
path as he drives from one area to another, he should be able to specify a
path that is compatible with both nodes and digipeaters. This is easily
accomplished by assuming that the LAST field in an UNPROTO digi list is the
HOME NODE and should be the ultimate destination for the UI frame through any
level 4 network. Any and all preceeding fields are assumed to be DIGI's only.
With this arrangement, the user could use an UNPROTO path of APRS VIA WIDE,
HOME so that any generic WIDE digipeaters would repeat his position to their
local area as would any WIDE NODES in the usual digi fashion. Only the
node that hears the direct packet would also forward it through the network
at level 4 to the HOME NODE. If only one field is included in the digipeater
string, it would be interpreted as both a digi and a HOME destination without
any difficulty. Digi's and NODEs would digipeat it, and nodes (hearing it
direct) would forward it at level-4. It is important that NODES hearing
digipeated UI frames from other digis do NOT enter the packet into the network,
to eliminate duplication. Only the ones hearing the direct signal should
be repsonsible for doing the level 4 routing..
EXAMPLE: A typical mobile just wanting to keep his spouse informed of his
whereabouts might want to just use the UNPROTO path of APRS VIA HOME. Then
his UI frames will be digipeated by the local HOME node or digi and will
also be routed back to HOME by all NET-NODES along his travels. If he also
wants to be seen by most HAMS in the areas of his travels, then he sets
his path to APRS VIA WIDE,HOME. If he travels through a region that has
both DIGIs and NODES, he might choose APRS VIA WIDE,WIDE,HOME. This way any
areas with digis would digipeat via WIDE,WIDE and if he gets to an area with
nodes which are aware of the path to HOME, then they will forward his packet
there.
Finally, since most regional area Tracking networks are dedicated to
APRS, the node should also permit the SYSOP to turn off other level 4
routing. Without this feature, such a network could be swamped if all of
the BBS and other CONNECTED protocol users began to use it, and the original
purpose of the network would be defeated.
Still, most of these APRS support ideas could be included in all NODES so
that a minimum of APRS tracking could be supported by ALL networks on all
frequencies, especially where there is not yet a dedicated APRS TRACKING
NETWORK. I think there are other undeveloped applications for shipping UI
frames through ALL networks which have not yet been explored. The capability
should be there, in any case, so that experimentation can proceed. Time will
tell. These few paragraphs were primarily written to the NODE CODE writers
such as John G8BPQ and Mr. Roberts of X1-J. But are included here in general
distribution for all to read.